I recently worked with a customer who was receiving an AADSTS5011: The reply url specified in the request does not match the reply urls configured for the application on his .Net Core Kubernetes container application with an Ingress Controller. When running from the Docker environment, there was no issue however, the redirect URI was configured for http://localhost:someport . Once deployed, the redirect URI ( as seen in the address bar of the browser at the Azure login prompt ) was set to his application properly however, the context was HTTP and not HTTPS. This is a problem because, in Azure AD, you have to set the reply URL scheme to be https, except for localhost. The customer was using Microsoft.Identity.Web for authentication.

SSL Was being terminated at the controller

The first issue we discovered was that the controller was terminating SSL. We worked with a Kubernetes engineer to get the controller setup for SSL passthrough, setting up a SSL certificate for the application and still, the context was set to HTTP instead of HTTPS and now, the customer was experiencing an infinite number of redirects until it just timed out ( the new error was “…too many redirects” ).

Mircrosoft.Identity.Web not fully ready for GA

Even though the customer found the Microsoft.Identity.Web library on our GitHub, this library isn’t fully ready for GA and may not be anytime soon ( a fact that I hope has been noted on the GitHub by now ). However, we did finally resolve this last issue by simply specifying the Context.Request.Scheme to be “https” in code. This was presented from an ASP.NetCore engineer with this document: https://docs.microsoft.com/en-us/aspnet/core/host-and-deploy/proxy-load-balancer?view=aspnetcore-2.1#forwarded-headers

Here is the code snippet where the final fix was done in the applications startup.cs file:

public void Configure(IApplicationBuilder app, IHostingEnvironment env, ILoggerFactory loggerFactory)

{

    app.Use((context, next) =>

    {

        context.Request.Scheme = “https”;

        return next();

    });

    app.UseForwardedHeaders();

Conclusion

Even though the Microsoft.Identity.Web library isn’t fully GA ready yet and we experienced serious difficulties in the Kubernetes environment, a multi-faceted resolution was found for the problem. Hopefully, this blog post makes the experience less painful for the next developer!